规范
怎么让代码规范执行下去
一、系统里面存在的糟糕代码情况有：
代码规范，命名规范和注释
公用代码的抽取和封装
性能低下的代码
表现层、业务层、数据持久层位置存放混乱问题
二、问题
岗位调动，接手一个新的项目组。旧项目一踏糊涂，全部无规范和设计。
组成员各做各的，毫无团队协作能力，更别说团队凝聚力。简直不能更糟糕。
新项目、新成员，新项目重新做了明确规范和框架设计，但组员很多时候不能很好的按照规范进行开发
我有强迫症
三、开始犯的错误，也是最笨的做法
定时核查，自己看到不正确代码同时指出，让开发优化，缺点：
比较耗时，没有很多时间来检查所有开发代码
周期长，这个过程要一直持续很久，才能有效果
效果慢
容易导致组员开发反感，这很重要，任何事情重复了次数多了，都无法避免
四、解决方案
选一个检查负责人，定一个周期（一周），每周三出一份检查报告。
报告放入文档，附带截图和问题说明、以及所随机抽查的文件，发送全组
负责人规定最后修复时间，所属问题对应开发修复后并回复
五、要点
负责人检查这个过程，他会自己认真考虑问题和优化方案，这很重要，负责人过程肯定印象深刻，可以避免再犯
实际中，负责人检查的肯定有不少遗漏和不正确或要点没指出，特别是首次作为检查人时
自己通过检查文档，过一遍，把负责人考虑不全的同他当面沟通指正， 同时让他更新问题文档， 这里可直接提高他的编码能力
这个检查过程，提高最大的是负责人。所以负责人每周期一换，轮流来， 当他们经历规范负责人后，对项目归宿感和规范要求会大有提升，后面至少负责人会认真写出正确的编码
相信经过几轮后，每个开发最后都得到大量提高和合作能力
项目经理可节省大量时间，且提高开发水平、代码规范、性能、代码重用等优化
六、总结
- 把问题抛出给组员，并尝试让他们独立解决
- 大部分时候，只要引导方法正确，他们很处理的很好
- 非必要的话，需避免自己独自扛着问题，让组成员处理、进步变得优秀才是‘可持续发展’模式，这需要一个过程，虽然难，但一定要进行